1. Progressive Enhancement

   Content is king; make sure it loads above all else. Then make it visually approachable. Then make it interactive.
2. Reusability

   Build patterns to make coding easy and brand consistency will happen automatically.
3. Responsive Design

   Start by thinking about smaller screens, and grow from there. Be responsive, create adaptively.
4. Prototyping

   The best way to see how a design works is to build it.
5. Communicating

   Not sure what pattern to use? Need a new pattern? Something doesn't seem quite right? Let's talk about it!
6. Technique

   Consistency isn't just for branding. Adhering to coding standards can help everyone.

Writing the code for beautiful designs and interactions is fun, but in the end people visit most sites to gain information. In this light, it is key that the information given by a page is accessible to a wide audience and not hidden behind fancy styles and javascript. You can never have 100% control over the client's abilities, and so it is important to deliver content from the ground up with a strong foundation. If nothing else renders but HTML, it will still be readable, accessible and functional if semantic HTML is used.

There is an assumption with many people that progressive enhancement means you aren't allowed to do the fun stuff, too. This is not true! The important thing to remember is that you are starting with a strong foundation on which to build upon. Once you have that, it is much easier to work with css and javascript, because you have the node structure created already. All you need is to consider the amount of time required to create each layer.

What to Consider:

• Which parts are absolutely necessary for the end user?
• Which are pure design choices?
• Can performance be enhanced by moving some things to the back end?
• Am I using HTML elements that make sense for the content inside of them?

Reusability is all about efficiency, and is one of the main reasons we have created this library. It means that we can always be sure what something will look like. It means that we maintain branding consistency. It means that we can make needed changes in one place, and all of our properties will be updated.

It also means that our front end code is easy to use, for developers and non-developers alike. A dev who needs to add a certain component can simply copy and paste the code into their application. A business representative who wants to know what their content will look like can simply look at an example to get an immediate idea of what to expect.

Because we are always updating and changing, this component library is a living document and sometimes we will need to create new patterns. When developing interfaces, have an eye towards reuse. Unless the use case warrants a new pattern or collection of fields strive to use the same markup across applications in such a way where an update to the pattern only needs to be made once.

What to Consider:

• Have I seen something like this before?
• Can we use an existing pattern to do this?
• Where else could we use this new pattern?

We can't predict what devices or input types our stakeholders will want to use to interact with our interfaces, so we support all devices and input types (keyboard, touch, mouse). Because mobile devices are growing as a primary interface across the world, we use the mobile-first approach to streamline layouts and tasks.

Planning for a small screen and assuming the components will expand to fit can make development easier. Often times a component coded for a small screen will look just as good on desktop sizes. It also means that by default, we'll have a decent layout even for older browsers. We aim to support all browsers, but we optimize for the most recent versions.

Additionally, by writing semantic code and styling for minimal devices, we help ensure that we meet accessibility guidelines. HTML supports content by providing context. Styling supports that content by giving it visual context, and we use relative units, particularly "rems" to make sure that no matter the screen size or zoom everything fits as intended. All functionality should be achievable without the need for javascript, which may not be accessible with some devices or in some locations.

What to Consider:

• Does this design take into account smaller devices?
• Is my HTML semantic?
• Does my code pass accessibility standards?
• Have I tested my code in multiple browsers and devices?

Rather than depend solely on static images, wireframes and written documentation to determine how a component should be built, we prefer to prototype as much as possible. While imagery is a good start, it is easier to understand the limitations and effects of what we can do with functional code. Particularly with non-developers, having a hands-on demonstrable piece of work helps to show technical limitations visually.

Creating prototypes also helps to speed up work. After creating something basic, you have already created the foundation of the component. Even if tweaks are needed, with a prototype already made it is easy to put that code into place.

Prototyping can be done in many environments. Creating something in an existing code repository would be an obvious choice, because it will already be connected to our library. However, creating something from scratch in Notepad or even just adjusting styles live in a browser's dev tools can be useful ways to demonstrate requested changes and their effects on other page components.

What to Consider:

• Will creating a prototype help illustrate the problem?
• What requirements need to be completed?
• What resources will a proof of concept require?
• Is my code testable?

Because front end code is what drives the visual aspects of our web properties, it is often the most commented on for desired changes and updates. Because of this, we need to be able to communicate well not only with other developers but with business partners and our user base to better understand their needs and to explain our reasonings. We also do our best to keep in contact with other teams to stay on top of updates and future work, to help make better solutions and estimates of time required to deliver.

It is also common that new developers or developers unfamiliar with fron end code will have a need to use our work. In that vein it is important that we document as much as possible. We have tried to make this library a useful tool for everyone in the business to use in one way or another. It is also important to us that our code is readable and understandable, and so writing clearly and using helpful comments in code is key.

Finally, because the component library is our source for all styling and scripting and front end is a "shared service", it is important to make everyone aware when changes are coming. Nobody likes to be surprised at an inopportune time. We are all part of the same team, so let's work together as much as possible!

What to Consider:

• Have I made my changes clear to all teams?
• Have I communicated any red flags?
• Does my code include readable comments?
• Is my component documented in the library?

In addition to commenting, we try to adhere to a few other coding standards as well. This helps ensure that code is consistent from one team to the other, and helps to unify everything into a single entity. Here are some things to look for:

HTML

• HTML elements should make sense with the content they contain.
• HTML should never be used solely for layout.
• Element names and attributes should be written in lower case.
• Use aria attributes where necessary for accessibility, but know that they are not always needed.
• ID's should be used when a unique link or javascript connection needs to be made. They should be written "inCamelCase"
• Classes should be used for styling, less often as javascript hooks. They should be written in lower case.

CSS

• CSS is powerful, use it wherever possible in favor of javascript.
• Avoid targeting elements specifically. Use classes wherever possible.
• Class names should be meaningful to their purpose.
• When writing large batches of rules, alphabetize the rules for easy findability.
• When using SASS, don't nest more than two levels in.

JavaScript

• Write as little code as possible.
• Write as many comments as necessary.
• Target nodes via their ID if possible.
• Avoid using third party plugins whenever possible.
• Test test test!

General

• Indent your code for readability.
• Add comments to clarify your code.

But you should strive for it anyway, and don't be afraid to ask for help!

1. Research

   What problem(s) are we trying to solve? What are we building? What data do we have to help understand the problem? Do we have customer feedback to support the project?
2. Plan

   Do we have specific user stories? Create user flows to better understand the journey, and make sure you validate using audience data. Define red routes to help identify, prioritize, and eliminate obstacles.
3. Explore

   Discuss the project with peers. Prototype, prototype, prototype, and test your prototypes with real users. Be prepared to throw away most of what you make. It’s much cheaper to rework your approach at this stage. Work with the content team and use real content at this phase.
4. Create

   Is this responsive? What does it look like on mobile? Tablet? A large monitor? Reuse existing elements and patterns. Follow style guidelines. Follow WCAG 2.1 AA guidelines.
5. Feedback

   Be specific and clear with error messages. Give immediate feedback of successful actions. Show a loader if users must wait.
6. Finalize

   Use images, icons, and colors consistently. Always follow the design guide and try to keep things clear and simple. The design should always provide the user a clear path forward... not distract.
7. Delight

   Add micro copy where appropriate. Think about micro interactions. Will motion help build meaning about spatial relationships, functionality, and intention?
8. Analyze

   Can we user test? What KPIs will we look at for success? What do we expect to achieve? Are data collection measures in place? Can we show efficiency gains (e.g. time on task)?

While it can be tempting to jump straight into designing a solution, it’s essential to make sure the right problem is being solved. Nothing is more costly than building the wrong thing.

Problem definitions should be based on data, not opinion. Analytics, journey mapping, and qualitative and quantitative data gathering techniques are valid ways to confirm that a real problem exists.

Make sure your problem statement is correctly sized. It should be broad enough to allow for creative solutions, while narrow enough to constitute a single, solvable problem. Prototyping and hypothesis testing can help confirm that you have identified the right problem to solve.

Content should form the foundation of all design decisions. If we design in the absence of real content, we are creating the packaging before we know what’s going in it.

Start with Content

Design the user flow first. This allows us to identify pages and content needs. Think about strategic objectives and red routes during this process.

Wireframing

Map the user flow to the wireframe. By working content-first, we can prioritize the wireframe development accordingly:

• Content structure
• Interaction design
• Visual design

Iteration

Iterating on the interactions through low-fidelity wireframing will help us better understand and control the flow of the experience. As you work keep the following in mind:

• Real Content. Use real content, never use “lorem ipsum” or placeholder content.
• Collaborate. Involve the content team often as the wireframes evolve.
• Test. Test your wireframes with real users as frequently as possible.
• Progressive Enhancement. All core content needs to be accessible on all devices.
• Think Mobile-First. Make sure we adequately represent what pages look like on mobile. Ideally, start making content and interaction decisions at the mobile breakpoints before designing the desktop experience.

Progressive enhancement means one thing: delivering what can be supported to the right platform. It’s not about supporting the oldest browsers. It’s not about avoiding JavaScript. It’s about making sure the core content is always accessible. We progressively enhance in a layered approach. Once we design the content layer, we enhance by adding the design and interaction layers independently.

Layer 1: Content

The first layer is clean, semantic HTML. This allows text-based, speech-based, antiquated and robotic user-agents to navigate the content of your website properly. Semantic HTML will take you 90% of the way to a site that works with most assistive technologies.

Layer 2: Design

The second layer is CSS. This allows visual-based user-agents to display or alter the visual representation of our website’s content.

Layer 3: Interaction

The third layer is JavaScript. This allows user-agents that are capable to provide users with enhanced features and usability.

Good interaction design is driven by a human connection.

Goal-Driven Design

We need to understand our users and design solutions for them. Our design approach should be people-centric and inclusive. Personas, user scenarios, experience maps are all tools to help us focus on the user.

Usability

Usability is the bare minimum of interaction design. A system must first be usable before it can be enjoyable. We want our systems to be effortless to use.

Affordances and Signifiers

Make things obvious. Without signifiers (e.g., blue underlined links), users won’t be able to perceive what they can do.

Learnability

We use consistent UI patterns that will be familiar to our customers. Our component library contains components that provide a strong level of predictability.

Feedback and Response Time

Feedback is the heart of the interaction. Micro-interactions and subtle animations, in response to a user’s action, will provide satisfaction and a sense of accomplishment. If a process takes too long to complete, we should provide the appropriate feedback to the customer (like a loading icon).

The faster a site loads, the better the user experience. A few things that we must do to assure a fast-loading site are:

• Minify and concatenate all JavaScript and CSS
• Make sure all images are properly optimized
• Include CSS at the top, JavaScript at the bottom
• Avoid using unnecessary images that don’t add value to the page
• Avoid plugins unless necessary (most plugins are bloated and add HTTP requests)
• Create animations using CSS instead of JavaScript

Image Optimization

All production images should be properly optimized. ImageOptim is a great tool for providing lossless compression and removing bloated metadata. Online optimizers include tinyPNG and Jpeg.io.

HTML

When writing HTML, strive to be semantic, concise, and effective.

• CSS references should be placed at the top of the document.
• JavaScript references should be placed at the bottom of the document.

Reduce HTTP Requests

Eliminate any features that do not improve the user experience. These may be:

• Unnecessary images
• Unnecessary JavaScript
• Excessive CSS
• Unnecessary plugins